1. New Product Development (NPD)
New Product Development (NPD) is the process of bringing a new product to market. This is a process that encompasses the course of events from the early stages of the product inception – with a lot of fuzzy ideas and fuzzy thinking – to the final launching stage of the new product. The process should assure the appropriate translation of the stakeholders' requirements into the product design and development.
2. Do the Right Project - The Funneling Process
The funneling process is a process that is an essential part of the NPD process. One of the challenges in NPD processes is to manage the Fuzzy Front End at the beginning of the funneling process [Katz G, 2011]. The Fuzzy Front End (see Figure 1) occurs while:
a) Defining the project scope based on stakeholders' needs and expectations;
b) Defining the specifications to be designed so as to satisfy the requirements.
The funnel model was suggested to emphasize the selection among different alternatives during the NPD process reaching one coherent product at the end of the funnel [Steven C. and Kim B. Clark, 1992]. The challenge is to improve the way alternatives are discussed and selected. In this paper, we focus on this gap.
The NPD process has been described in the literature in a multitude of ways, one of which is depicted in Fig. 1 below [5]. The process is described as a five-step funnel, portraying the narrowing down of the initial myriad of ideas into the final delivered product.
Fig. 1. The funneling process
3. The Fuzzy Front End (FEE) Process
The initial stages of the NPD process are termed the "fuzzy front end", as they are the messy "getting started" period of the new product development process. It is in the front end where the organization formulates a concept of the product to be developed and decides whether or not to invest resources in the further development of an idea. The Fuzzy Front End begins with the initial search for new opportunities, through the formation of an idea to the development of a precise concept. The Fuzzy Front End ends when an organization approves and begins the project.
The Fuzzy Front End presents many challenges. Stakeholders' requirements need to be understood and formulated. In large systems it may often be impractical to model entire systems due to sheer size and complexity. The alternatives' creation process is often manual, resulting in missed alternatives that may have been the best choice. Our challenge is to improve the way alternatives are discussed and selected.
A well-planned and organized commencement of the project is known to dramatically improve the probability of the success of the entire project. This paper presents a methodology using a Simulation Based Planning (SBP) workshop during the early stages of a program. The results of the workshop are: the selection of the preferred design alternative based on cost/benefit/risk analysis, a baseline work plan that coherently reflects this design alternative, the allocation of resources, and a risk mitigation and abatement plan.
The particular process proposed in this paper uses a simulator as a tool to support planning and testing the robustness of the project work plan.
4. The Decision Support System- The Project Team Builder (PTB)
The Project Team Builder (PTB) is a Decision Support System designed to support New Product Development teams in the Fuzzy Front End of the NPD process [8-12]. It is based on the following principles:
· A simulation approach—the Project Team Builder simulates new product development projects. The simulation is controlled by a simple user interface and no knowledge of simulation or simulation languages is required.
· A case study approach—the Project Team Builder is based on a simulation of case studies. Each case study is a new product development project performed under schedule, budget and resource constraints, in a dynamic stochastic environment. The details of these case studies are built into the simulation and all the data required for analysis and decision-making is easily accessed by the user interface. A user-friendly case study generator facilitates the development of new case studies as required.
· An integrated approach—several NPD projects can be managed simultaneously on the PTB. These projects share the same resources and a common cash flow.
· User friendliness and GUI—the Project Team Builder is designed as a Decision Support System. As such, its Graphic User Interface (GUI) is friendly and easy to learn. Although quite complicated scenarios are simulated, and the decision support tools are sophisticated, a typical user can learn how to use the Project Team Builder within an hour.
· A Pareto efficient frontier analyzer - the Project Team Builder is modelling alternative designs of the new product. For each alternative a model of the system is created that takes into account the value created, the cost and resources associated with that alternative, its duration and the risk associated with it. The Pareto efficient designs are identified and presented in the form of an efficient frontier.
· Efficient designs are fine-tuned by a simulator engine that simulates the risk associated with each alternative, its cost, schedule and the value it generates for the stakeholders.
· The Project Team Builder provides Decision Support in New product development for today’s competitive environment. The PTB approach to guide decision making is shown in Fig. 2.
Fig. 2. The PTB approach
Phase 1 – Develop your project tradespace alternatives along with estimates of cost schedule and resources required for each alternative.
Phase 2 – Model - Model the tradespace alternatives into the Scenario Builder. Refine your scenario focusing on scope, time, cost, resources and quality. Model your project risk. Export your scenario to Project Team Builder.
Phase 3 – Generate the Efficient Frontier and run your preferred design on the Project Team Builder. Record your lessons learned so they can be used to optimize your project plan.
Phase 4 – Fine tune your project plan - Refine scope, time estimates, resource estimates, cost estimates, quality parameters, and update your risk management plan.
Phase 5 – Execute your fine-tuned plan - begin your project with a better understanding of how the plan is likely to unfold. Instill confidence in your project stakeholders as a result of advanced schedule risk analysis.
Phase 6 – Manage the plan - Update your scenario based on lessons learned in the scenario builder; run your update scenario in the project team builder. Refine your project plan with lessons learned. Continue this process till you develop a robust good plan.
The PTB combines classical project management domains, like scheduling of activities, with the management of requirements, as it offers a module for system requirement management that supports the process of selecting alternative designs that determine system performance. The simulator allows the generation of a project scenario that includes the activities, the probability distribution of lead time in a stochastic, resource-constrained project network, duration, dependencies and necessary resources and staff. Based on the input, the simulator offers a forecast for the project cost, schedule and the product quality.
This way, users have the possibility of interactively experiencing the decision making process by getting an opportunity to cope with the results of these decisions on the execution of the project.
The Project Team Builder generates the efficient frontier of potentially attractive designs and allows the user to evaluate the cost schedule, as well as quality and risk associated with each design (see Figs. 3 & Fig. 4).
Fig. 3: The Efficient Frontier of the various tradespace alternatives.
Fig. 4: Risk analysis of efficient design
5. Do the Project Right – Methodology Flowchart
The Fuzzy Front End stage is one of the most significant drivers of project success. Well-defined projects cost less, take less time to execute, and operate better (Cooper 2011). Due to its significance, the proposed methodology carries out the required steps by employing a well-planned and structured process. The highlight of the methodology is a workshop, which utilizes the Project Team Builder to obtain immediate feedback regarding the effectiveness of various tradespace alternatives.
The details of the process steps are described in the following section.
Fig. 4. (a) The Fuzzy Front End methodology using Simulation Based Planning; (b) The PTB approach.
6. Detailed Description of the Methodology for the Simulation Based Planning Workshop of the Fuzzy Front End Stage
6.1. Discovery
In this stage the company collects information about the project goals and constraints: Customer and other stakeholders' needs and expectations are identified and analyzed; major design alternatives are defined; project budget allocated and time-to-market defined.
6.2. Definition
In this stage the major design alternatives are generated.
6.3. Design
The design stage focuses on the efficient frontier of a few selected alternatives. Based on the project constraints the core team prepares the project plans and simulates the plans using lessons learned to refine and improve the plan.
6.4. Development
Having complied with the project data set, alternative project plans are constructed, all of which are compliant with the project constraints reflected by the data set (such as project duration, costs and risk level). The purpose of this step is to evaluate each project plan in order to select the most efficient plan, i.e., the project plan on the efficiency frontier.
The proposed methodology is centered around a workshop which assembles all the project's key stakeholders in order to jointly work out the details of the alternative project scenarios, based on the project basic data set, including developing the program schedule, identifying risks and opportunities, critical actions, and clarifying key assumptions.
Workshop event stages:
1. Identification of the stakeholders
2. Preparation of the workshop
3. Execution of the workshop
4. Summary and analysis of the workshop outputs
6.5. Delivery
The workshop deliverables is comprised of a baseline work plan, including its associated resources, budget and risk identification and abatement plan. These deliverables have been agreed upon and approved by the stakeholders.
This ultimately culminates in the project kickoff, which launches the project execution stage.
7. Industry Beta sites
The methodology and tool were used in five workshops performed at RAFAEL on five different projects
Each project was analyzed according to the following parameters: financial scope (in $M) and its division between R&D and production, project complexity level (in terms of technology innovation), number of participating disciplines in the workshop and the project duration. The analysis showed that the workshop can be conducted on a range of project types and sizes involving a variety (up to 15) of disciplines.
8. Summary
The contribution of this paper is twofold. From the practice perspective, we present a methodology that helps project stakeholders, managers, and engineers to cope with the high complexity of the Fuzzy Front End. From the theoretical perspective, we suggest the notion of patterns to be used for management and architectural aspects in the funneling process.
A methodology for applying simulation-based planning in engineering programs was successfully implemented on a variety of projects in industry. Our experience so far shows that the investment of time and resources in conducting the workshop at these early stages of the project significantly contributes to the robustness of the project work plan and the achievement of shared understanding amongst team members and other stakeholders.
Acknowledgements
This research was supported by the Bernard M. Gordon Center for Systems Engineering at the Technion—Israel Institute of Technology.
References
[1] Van der Geer J, Hanraads JAJ, Lupton RA. The art of writing a scientific article. J Sci Commun 2000;163:51-9.
[2] Strunk Jr W, White EB. The Elements of Style. 3rd ed. New York: Macmillan; 1979.
[3] Mettam GR, Adams LB. How to prepare an electronic version of your article. In: Jones BS, Smith RZ, editors. Introduction to the electronic age. New York: E-Publishing Inc; 1999. p. 281-304.
[1] Söderquist, K. E. (2006). Organising knowledge management and dissemination in new product development: lessons from 12 global corporations. Long Range Planning, 39(5), p. 497-523.
[2] Cooper, Robert G., 2001. Winning at New Products, Cambridge, MA: Perseus Publishing.
[3] Cooper, Robert G., and Elko J. Kleinschmidt. New Products: The Key Factors in Success. Marketing Classics Press, 2011.
[4] Amaral, D., Rozenfeld, H., & de Araujob, C. (2007). A case study about the product development process evaluation. In Complex Systems Concurrent Engineering pp. 211-218. Springer London.
[5] Katz G., Rethinking the Product Development Funnel, http://www.innovationexcellence.com/blog/2011/11/29/rethinking-the-product-development-funnel/#sthash.I3MNDA0b.dpuf, November, 2011.
[6] Wheelwright, Steven C. and Kim B. Clark, 1992. Revolutionizing Product Development, New York, NY: The Free Press.
[7] McGrath, Michael E., 1996. Setting the PACE® in Product Development, Boston, MA: Butterworth-Heinemann.
[8] Hauser, John R., 2008. Note on Product Development, p. 3. Cambridge, MA: MIT Sloan Courseware.
[9] Parush, A., L. Davidovitz and A. Shtub, Simulation-based Learning in Engineering Education: Performance and Transfer in Learning Project Management, Journal of Engineering Education, October 2006, pp. 289–299.
[10] Davidovitch, L., A. Parush and A. Shtub, Simulation-based Learning: The Learning-Forgetting-Relearning Process and Impact of Learning History, Computers & Education, April 2008, Vol. 50, No. 3, pp. 866–880.
[11] Davidovitch, L., A. Parush and A. Shtub, The Impact of Functional Fidelity in Simulator based Learning of Project Management, International Journal of Engineering Education, March 2009, Vol. 25, No. 2, p. 333–340(8).
[12] Shtub, A., A. Parush and T. Hewett, Guest Editorial: The Use of Simulation in Learning and Teaching, International Journal of Engineering Education, March 2009, Vol. 25, No. 2, p. 206–209.
[13] Parush, A., L. Davidovitch and A. Shtub, Simulator-based Team Training to Share Resources in a Matrix Structure Organization, IEEE Transactions on Engineering Management , Vol. 57, No. 2, May 2010, p. 288–300.
[14] Shtub, A., Simulation Based Training (SBT) – the Next Generation of Project Management Training. PM World Journal ,Vol. II, Issue XI – November 2013.
[15] Zwikael, O; Shtub, A. and Chih, Y., Simulation-Based Training for Project Management Education: Mind the Gap, As One Size Does Not Fit All, Journal of Management in Engineering, Forthcoming